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ABSTRACT 


Currently, all Missile Defense Agency (MDA) instrumentation radars are land-based at 
Reagan Test Site (RTS) in the Marshall Islands and the Pacific Missile Range Facility 
(PMRF) on the Hawaiian island of Kauai. The dependency on land-based radars produces 
significant gaps in radar coverage of planned ballistic missile defense system (BMDS) 
tests. The S.S. Beaver State is a former cargo ship that was converted to a crane ship. 
The purpose of a crane ship is to unload/load other ships at ports with inadequate 
facilities. When the Beaver State was converted to a crane ship, three large cranes were 
installed. The size of the ship and generators make the Beaver State suitable to host the 
first X-Band Test Radar (XTR-1) and the second Transportable Telemetry System (TTS- 
2). There are five major efforts in the conversion process: 1) Ship reactivation; 2) 
Modification of the ship to host the primary sensors, the adjunct systems, and the 
respective operators; 3) Installation and integration of the primary sensors and adjunct 
systems; 4) Development, installation, and certification of the communications system; 
and 5) Coast Guard certification. This thesis will review the history of the modification 
design and communications system development aspects of this conversion process, 
review the Department of Defense Architectural Framework (DoDAF), assess the 
applicability of DoDAF to the Beaver State conversion process, and suggest opportunities 
for improvement of similar MDA test asset development programs. 


V 



THIS PAGE INTENTIONALLY LEFT BLANK 


VI 



TABLE OF CONTENTS 


I. INTRODUCTION.1 

A. BACKGROUND.1 

B. PURPOSE.4 

C. RESEARCH QUESTIONS.4 

D. BENEFITS OF STUDY.4 

E. SCOPE AND METHODOLOGY.4 

1. Scope.4 

2. Methodology.5 

II. HISTORY OF THE BEAVER STATE CONVERSION.7 

A. BACKGROUND.7 

1. MDA Flight Testing.7 

2. Some Other Sea-Based Sensor Platforms MDA Has Used to 

Support Testing.9 

a. MV Pacific Collector. . 10 

b. Observation Island . 12 

c. SBX . 13 

3. Pacific Tracker Concept.14 

B. PACIFIC TRACKER PROJECT.15 

1. Mission.15 

2. Organization.17 

3. Acquisition Approach.18 

4. Technical Approach.20 

5. Schedule and Milestones.22 

6. Design Evolution History.23 

a. Acquisition Strategy Panel . 23 

b. Systems Requirements Review . 24 

c. Preliminary Design Review . 34 

d. Critical Design Review . 35 

e. Contract Award . 39 

III. REVIEW OE DODAF.41 

A. INTRODUCTION.41 

B. OPERATIONAL VIEW.43 

C. SYSTEMS VIEW.43 

D. TECHNICAL STANDARDS VIEW.44 

E. PRODUCTS.44 

F. DODAF SUMMARY.47 

IV. ANALYSIS OF THE APPLICABILITY OE DODAF TO THE PACIEIC 

TRACKER CONVERSION.49 

A. INTRODUCTION.49 

B. SELECTED BEA VER STATE CONVERSION DODAF PRODUCTS ...49 

vii 








































1. All View-1 Overview and Summary Information.49 

2. OV-1 High Level Concept Description.50 

3. OV-2 Operational Node Connectivity.51 

4 OV-3 Operational Information Exchange Matrix.56 

5 OV-4 Organizational Relationships.58 

6 OV-5 Operational Activity Model.63 

7 SV-1 System Interface Description.66 

8. SV-2 Systems and Services Communications Description and 

SV-6 Systems Services Data Exchange Matrix.67 

C CONCLUSIONS: POSSIBLE IMPACT OF DODAF ON THE 

PACIFIC TRACKER PROGRAM.69 

V. SOME IMPLICATIONS FOR OTHER MDA TEST ASSET 

DEVELOPMENT PROJECTS.73 

LIST OF REFERENCES.75 

INITIAL DISTRIBUTION LIST.77 


viii 















LIST OF FIGURES 


Figure 1. The S.S. Beaver State as it is being towed from Suisun Bay Reserve Fleet 
in Benicia, CA to be temporarily berthed at Alameda, CA. (T. Amundsen, 

personal communication, 4 April 2008).2 

Figure 2. The MV Pacific Collector. The twin 7m dishes of the Transportable 

Telemetry System are seen in the aft section of the ship (T-AGS-29, n.d.). ...10 

Figure 3. USAV Worthy.11 

Figure 4. Observation Island: The S-Band phased array is seen on the aft deck, and 

the X-Band radar is seen atop the house, aft of the smokestack (USNS 

Observation Island, 2001).12 

Figure 5. Sea-Based X-Band Radar: The X-Band radar is under the large center 

dome (SBX, 2007).13 

Figure 6. Organization of the Pacific Tracker and major sensors projects.18 

Figure 7. Schedule for the project presented at ASP by DTR.23 

Figure 8. MARAD’s power option 1.26 

Figure 9. Power option 2.27 

Figure 10. SRR power option 3.28 

Figure 11. TTS antenna configuration with 37 ft high radomes mounted on the main 

deck.31 

Figure 12. TTS antenna and deck configuration for option 2.32 

Figure 13. Option 3 with 42 ft tall radomes and antennas mounted on hatch coamings ..32 

Figure 14. One line diagram of the power generation and distribution system 

presented at the CDR.36 

Figure 15. Interrelationships among DoDAF views.42 

Figure 16. DoDAF Products.46 

Figure 17. Architecture Products and their Applicability.47 

Figure 18. Pacific Tracker Overview and Summary Information.50 

Figure 19. Pacific Tracker High Level Concept Description.51 

Figure 20. OV-2 Operational Node Connectivity Description.53 

Figure 21. OV-2 Operational Node Connectivity Description Test Event Data.55 

Figure 22. OV-2 Operational Node Connectivity Description Test Event Voice.56 

Figure 23. OV-3 Operational Information Exchange Matrix with Test Event Data.57 

Figure 24. OV-3 Operational Information Exchange Matrix with Test Event Voice.58 

Figure 25. OV-4 Organizational Relationships August 2007.60 

Figure 26. OV-4 Organizational Relationships January 2009.61 

Figure 27. OV-4 Organizational Relationships, Possible End State Pacific Tracker.62 

Figure 28. OV-4 Organizational Relationships, Possible End State Pacific Tracker 

(Flight Test Operations).63 

Figure 29. OV-5 Operational Activity Model.65 

Figure 30. OV-5 Operational Activity during test execution.66 

Figure 31. SV-1 System Interface Description.67 

Figure 32. SV-2 Systems and Services Communications Description.68 

Figure 33. SV-6 Services Exchange Matrix.69 


IX 


































THIS PAGE INTENTIONALLY LEFT BLANK 


X 



LIST OF TABLES 


Table 1. MV Pacific Collector Specifications.11 

Table 2. USAV Worthy Specifications (Missile Range Instrumentation Ships, 

2008).12 

Table 3. USNS Observation Island Specifications (USNS Observation Island, 

2001).13 

Table 4. SBX specifications.14 

Table 5. Projected costs by FY for Pacific Tracker development and operation.19 

Table 6. Power requirements based on XTR-1 and TTS ICDs.25 

Table 7. APL summary conclusions for bandwidth requirements in kbs.33 

Table 8. MARAD’s load analysis results.37 











THIS PAGE INTENTIONALLY LEFT BLANK 



EXECUTIVE SUMMARY 


The conclusion of this thesis is the application of the Department of Defense Architecture 
Framework (DoDAF) to the design effort to convert a crane ship, Beaver State, to a range 
instrumentation ship would not have been very useful. The effort to convert Beaver 
State, to be re-named Pacific Tracker, has five major efforts: 1) Ship reactivation, Beaver 
State had been mothballed in the Department of Transportation, Maritime 
Administration’s (MARAD) inactive reserve fleet; 2) Modification of Beaver State to 
host the Missile Defense Agency’s X-Band Test Radar (XTR-1), one of its Transportable 
Telemetry Systems (TTS), adjunct systems, and respective operators; 3) Installation and 
integration of XTR-1, TTS, and adjunct systems; 4) Development, , installation, and 
certification of the communications system; 5) Coast Guard certification. The major 
engineering efforts in the conversion process that were considered in this thesis are: 1) 
The design of the modification for the ship to host the radar, telemetry, adjunct systems, 
and the respective operators; and 2) the design of the communications system. DoDAF 
with its emphasis on interoperability would not have significantly impacted the major 
ship modifications such as: modifications to house system operators; TTS placement, or 
electrical system modifications. Application of DoDAF to the communications system 
development would also not have a significant impact largely due to the evolutionary 
aspect of the communication system and the maturity of the established communication 
architecture. 

This thesis reviews other ships. Pacific Collector, Worthy, Observation Island, 
and SBX which MDA has used for BMDS testing. Then the Beaver State conversion 
project history and DoDAF are reviewed. Next, sample DoDAF products that could have 
been produced for the Beaver State conversion are developed. The assessment is made 
that the application of DoDAF would not have been very useful to the project and 
DoDAF’s utility for future MDA test asset developments would likely be similar. 
However, the development of DoDAF products relative to project organizations and 
processes did provide useful insights. The products OV-4 and OV-5, in particular, were 
useful. These products illustrated some complications with management of the project 
and operational processes. 
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I. INTRODUCTION 


A. BACKGROUND 

The objective of the Pacific Tracker (PT) is to provide a ship with instrumentation 
quality radar and telemetry reception systems for data collection on Missile Defense 
Agency (MDA) flight tests. The MDA’s mission is to develop systems to defend the 
U.S., our troops, and our Allies from ballistic missile attacks (Testing, 2007). The term 
“ballistic missile” covers a spectrum of systems. At one end of the spectrum are the 
Intercontinental Ballistic Missiles (ICBM) with ranges over 5,500 km. At the other end 
of the spectrum are the Short Range Ballistic Missiles (SRBM) with ranges as short as 80 
km (NAIC 1998). This wide spectrum calls for flight test geometries that span tens of 
kilometers to thousands of kilometers between the target launch site and the interceptor’s 
launch site. 

Currently, all Missile Defense Agency instrumentation radars are land-based. 
Principally, these radars are located at the Ronald Reagan Ballistic Missile Defense Test 
Site (RTS) located on Kwajalein Atoll in the Marshall Islands and the Pacific Missile 
Range Facility (PMRF) on the Hawaiian island of Kauai. The dependency on land-based 
radars produces significant gaps in radar coverage of planned ballistic missile defense 
system (BMDS) tests. Historically, targets simulating Intercontinental Ballistic Missiles 
(ICBM) have been launched from Vandenberg Air Force Base (VAFB), in California, 
towards RTS. The distance between VAFB and RTS is nearly 5,600 km. While radar 
signature and metric data of the objects within the test scene are required throughout the 
trajectory, most of the trajectory is out of range or view of the land-based radars. It is this 
gap in coverage that motivates the need for ship-based sensors. 

In this thesis, the term “radar signature data” refers to the radar derived data that 
is used to characterize an object so that it may be differentiated from other objects. 
Metric data refers to the motion and location of the object. 


1 




More recently, MDA has launched targets from Kodiak, an Alaskan island 
famous for its bears. MDA has also launched targets simulating Medium Range Ballistic 
Missiles (MRBMs) and SRBMs in various locations across the Pacific from U.S. Air 
Force C-17 aircraft and from the sea-based Mobile Launch Platform, the ex-USS Tripoli. 
Land on which to base a radar is simply not available in most cases. The mobile nature 
of the PT would allow MDA to greatly increase the radar and telemetry coverage on 
various tests locations across the Pacific. In order to meet data collection requirements, 
MDA has decided to convert the S.S. Beaver State to host the X-Band Test Radar (XTR- 
1) and the second Transportable Telemetry System (TTS-2). (The TTS-1 is currently 
installed on MV Pacific Collector.) 


Figure 1. The S.S. Beaver State as it is being towed from Suisun Bay Reserve Fleet 

in Benicia, CA to be temporarily berthed at Alameda, CA. (T. Amundsen, 
personal communication, 4 April 2008) 
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S.S. Beaver State is a former cargo ship that was converted to a crane ship. The 
purpose of a crane ship is to unload or load other ships at ports with inadequate facilities. 
This sort of ship may be used to help put ashore a surge of materiel to support sustained 
combat operations. When Beaver State was converted to a crane ship, three large cranes 
were installed. To power the cranes, two 1200 kW diesel generators were also added. 
This size and number of generators are needed to reliably provide electrical power to the 
radar. The size of the ship and generators make Beaver State suitable to host the XTR-1 
and TTS-2 systems and become Pacific Tracker. 


In the course of converting Beaver State into Pacific Tracker, the large cranes will 
be removed and other modifications to the ship will be necessary to host the XTR-1 and 
the TTS-2. There are five major efforts in the conversion process; 

1. Ship reactivation; 

2. Modification of the ship to host the primary sensors, the adjunct systems, 
and the respective operators; 


3. Installation and integration of the primary sensors and adjunct systems; 

4. Development, installation, and accreditation of the communications 
system; and 


5. Coast Guard certification. 


The major engineering efforts in the conversion process that are considered in this 
thesis are: 1) The design of the modification for the ship to host the radar, telemetry, 
adjunct systems, and the respective operators; and 2) the design of the communications 
system. This thesis will review the history of these two aspects of this conversion 
process, review DoDAF 1.5, assess the applicability of DoDAF 1.5 to the Beaver State 
conversion process, and suggest opportunities for improvement of similar MDA test asset 
development programs. 
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B. PURPOSE 


The purpose of this thesis is to: 1) Describe the conversion of SS Beaver State 
into SS Pacific Tracker, a project that did not incorporate DoDAF methodology; 2) 
Assess whether incorporating DoDAF would have improved the way the project was 
done; and 3) Provide recommendations on incorporating DoDAF into other MDA test 
asset development projects. 

C. RESEARCH QUESTIONS 

The following questions will be addressed in this thesis: 

1. How was the Beaver State conversion project conducted? 

2. What is DoDAF? 

3. What DoDAF products might have been produced to support the project? 

4. How may have the DoDAF methodology changed the way the project was 
done? 

5. Would the DoDAF methodology have been useful to the project or be 
useful in future MDA test asset development projects? 

D. BENEFITS OF STUDY 

This thesis will document practical lessons derived from the Beaver State 
conversion. Recommendations will be provided on the application of the derived lessons 
to other MDA one of a kind, or few of a kind, test asset development. 

E. SCOPE AND METHODOLOGY 

1. Scope 

The thesis will be limited to the applicability of DoDAF 1.5 to the design of the 
modifications for the ship to host the radar, telemetry, adjunct systems, and the respective 
operators; and the design of the communications system. 
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2 . 


Methodology 


The methodology used in this thesis research consists of the following steps: 

1. Review other ships MDA has used for BMDS testing, and review project 
history of the conversion. 

2. Review DoDAF. 

3. Develop a sample of DoDAF products that could have been produced for 
the conversion. 

4. Assess whether the DoDAF approach would have been useful to the 
project and its utility for future MDA test asset developments 
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II. HISTORY OF THE BEAVER STATE CONVERSION 


A. BACKGROUND 

1. MDA Flight Testing 

The MDA’s mission is to develop systems to defend the U.S., our troops, and our 
Allies from ballistic missile attacks (Testing, 2009). Missile Defense flight tests are 
designed to provide the Ballistic Missile Defense System (BMDS) with test scenarios 
sufficiently similar to hostile conditions to ascertain or demonstrate BMDS performance 
against the threat. The term “threat” refers to the ballistic missiles of hostile or 
potentially hostile nations. The term “ballistic missile” refers to “Any missile that does 
not rely upon aerodynamic surfaces to produce lift and consequently follows a ballistic 
trajectory when thrust is terminated” (MDA Glossary, n.d.). Ballistic missiles include a 
variety of systems. The largest and longest ranged systems are the Intercontinental 
Ballistic Missiles (ICBM). For example, the Russian SS-18 Mod 5 has a range of over 
9,600 km. The much smaller Russian SS-21 Mod 2, a Short Range Ballistic Missile 
(SRBM), has a range of only 75 km (NAIC 1998). In order to test BMDS against this 
wide variety of missile systems, flight test geometries often span hundreds of kilometers 
for the SRBM scenarios to thousands of kilometers for the ICBM scenarios. 

The BMDS is “An integrated system that employs layered defenses to intercept 
missiles during their boost, midcourse, and terminal flight phases” (MDA Glossary, n.d.). 
Today’s BMDS architecture includes satellites, radars, interceptor missiles, and battle 
management systems. The BMDS uses satellites and radars to detect and track threats 
once they have been launched. The battle management system uses track information 
from the satellites and radars to launch interceptor missiles toward the approaching 
threat. The interceptor missiles are designed to collide with and destroy the approaching 
threat missiles. A test scenario will often include a target missile launch towards the 
BMDS in such a manner as to simulate a hostile engagement. 
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To characterize a BMDS test, MDA collects information from a variety of 
instrumentation. Typical instrumentation includes radars, infrared imagers, visible 
imagers, and various sensors placed onboard the target missiles. Instrumentation radars 
are used to eollect metric and signature data on the test seene to eonfirm the 
characteristics of the target missile and the threat scene presented to the BMDS. Various 
sensors placed onboard target missiles may include thermocouples and motion sensors 
that are designed to help characterize the target’s performance. Data from the sensors 
onboard the target missiles are telemetered to surface reeeivers. In a similar manner, data 
from the interceptor missiles may also be telemetered to surface receivers. 

Currently, all Missile Defense Agency instrumentation radars in the Pacific are 
land-based. The premier radars are part of the Kiernan Reentry Measurements Site 
(KREMS) at the Reagan Test Site (RTS) in the Marshall Islands (RTS, n.d.). Other 
significant radar assets are at the Pacific Missile Range Facility (PMRF) on the Hawaiian 
island of Kauai. The dependency on land-based radars can produce significant gaps in 
radar coverage of planned ballistic missile defense system (BMDS) tests, and to avoid 
data gaps, less realistic engagement test geometries might be used. Historieally, targets 
simulating Intercontinental Ballistic Missiles (ICBM) have been launched from 
Vandenberg Air Force Base (VAFB) in California towards the U.S. Army Kwajalein 
Atoll (USAKA) Reagan Test Site (RTS) in the Marshall Islands. While signature and 
metrie data are required along the entire length of the trajectory, with a ground track 
covering 5,600 km, most of the trajectory is out of sight and view of the land-based 
radars due to the curvature of the earth. 

An instrumentation radar placed upon an appropriately positioned ship would 
elose much of the gap in radar eoverage in a VAFB to RTS trajeetory. A ship-based 
radar could also provide greatly improved eoverage of targets launehed from Kodiak, 
Alaska and other locations in the Pacific. MDA has also launched target missiles 
simulating MRBMs and SRBMs in various remote locations across the Pacific. In 
addition to launching targets from land bases, MDA has also air- and sea-launched 
targets. MDA has used U.S. Air Force C-17 aireraft to air launch a target over the Pacifie 
(News release 05-NEWS-0009, 2005). Near the Hawaiian island of Kauai, MDA has 
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used the Mobile Launch Platform (MLP), the ex-USS Tripoli. In June of 2008, MDA 
conducted a flight test off of Kauai where both the target and the interceptors were 
launched from vessels at sea. The target SRBM was launched from the MLP. Then, two 
interceptor missiles fired from the USS Lake Erie destroyed the target (Successful Sea- 
Based Missile Defense Intercept). MDA has requirements to collect radar data across the 
Pacific. A ship-based radar could have allowed MDA to greatly increase the radar 
coverage of these various test locations across the Pacific. MDA’s solution to close 
many of the radar data collection gaps across the Pacific is the XTR-1 radar aboard the 
ship. Pacific Tracker. 

2 . Some Other Sea-Based Sensor Platforms MDA Has Used to Support 
Testing 

The use of sea-based instrumentation to support flight testing is not a new 
concept. MDA has employed a number of instrumented sea-based platforms to support 
flight tests. These sea-based platforms include the MV Pacific Collector, the USAV 
Worthy, the Mobile Aerial Target Support System (MATSS), the USNS Observation 
Island (OBIS), and the Sea-Based X-band radar (SBX). None of these vessels were 
originally designed or built to support missile testing. Each vessel was designed and built 
for another function. However, in each case, the vessels were modified in order to accept 
the specialized instrumentation used in BMDS testing. The instrumentation on Pacific 
Collector and Worthy (Range Safety, n.d.) was developed and integrated on the ships 
specifically to support BMDS flight testing. MDA developed the SBX to be part of the 
operational BMDS (Testing, 2009). Even though the primary purpose of the SBX is not 
flight testing, MDA has been successful in collecting data with the SBX on MDA flight 
tests (News release 07-NEWS-0028, 2007). The MATSS and OBIS were originally 
developed for other related purposes. The PMRF developed MATSS to support naval 
weapons testing. The radars on OBIS are used to collect data on foreign ballistic missile 
tests (Cobra Judy, n.d.). However, the two systems, MATSS and OBIS, lend themselves 
well to supporting MDA flight tests. 
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a. 


MV Pacific Collector 



Figure 2. The MV Pacific Collector. The twin 7m dishes of the Transportable 

Telemetry System are seen in the aft section of the ship (T-AGS-29, n.d.). 

Pacific Collector (PC) is pictured in Figure 2. The ship is the former 
Texas Clipper II, a school ship for the Texas A&M University maritime program. Prior 
to serving as a school ship, the vessel was the USNS Chennault (T-AGS-29, n.d.). The 
MDA engaged the Maritime Administration (MARAD) to manage the modification and 
operation of the Texas Clipper II. Shortly after the modification, the Texas Clipper II 
was renamed Pacific Collector. The installation of the Transportable Telemetry System- 
1 (TTS-1) soon followed in late 2006. The twin 7m dishes and control shelters can be 
seen on the aft section of the PC. The PC was developed specifically by MDA to 
perform flight test telemetry data collection in the broad ocean area (BOA) where 
telemetry assets were not otherwise available. The PC and TTS-1 system have collected 
data successfully on several missions since late 2006. The current home port for the PC 
is Portland, Oregon. 
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DISPLACEMENT 

5,360 T 

LENGTH 

393 ft 

BEAM 

54 ft 

DRAET 

31 ft 

PROPULSION 

2 ALCO 251 V-12 DIESEL ENGINES, SINGLE 

SHAET, 3,400 SHP 


Table 1. MV Pacific Collector Specifications 



Figure 3. U S AV Worthy 


The USAV Worthy, pictured in Figure 3, is the former Stalwart Class 
Ocean Surveillance Ship USNS Worthy (USNS Worthy, n.d.). The U.S. Army Kwajalein 
Atoll (USAKA) acquired the ship in 1995 and installed the Kwajalein Missile Range 
Safety System (KMRSS) “to support TMD related remote site launch activities” (Range 
Safety, n.d.). TMD in this case stands for Theater Ballistic Missile Defense. The 
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primary purpose of the KMRSS is to terminate powered flight of an errant missile. The 
KMRSS uses redundant dishes to receive S-Band telemetry data from the missile. The 
data includes the missile’s position, velocity, heading, and other factors. This data is then 
processed to predict an impact point. If the calculated impact point threatens a protected 
area, then a command is sent over UHF to terminate thrust (Range Safety, n.d.). 


DISPLACEMENT 

2,262 LT 

LENGTH 

224 ft 

BEAM 

43 ft 

DRAET 

15 ft 

PROPULSION 

4 Caterpillar 398D 


Table 2. USAV Worthy Specifications (Missile Range Instrumentation Ships, 

2008) 


b. Observation Island 



Figure 4. Observation Island: The S-Band phased array is seen on the aft deck, and 

the X-Band radar is seen atop the house, aft of the smokestack (USNS 
Observation Island, 2001). 
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The ship was originally launched in 1953. The Navy acquired the ship 
three years later for use as a fleet ballistic missile test ship. OBIS was kept in reserve 
from 1972 to 1977 before it was converted to a missile range instrumentation ship. 
Observation Island is currently operated by the Military Sealift Command (MSC) for the U.S. 
Air Force Technical Applications Center. The ship is host to S-Band phased array radar and 
X-Band dish radar. The OBIS is used for “worldwide, monitoring compliance with strategic 
arms treaties and supporting U.S. military weapons test programs” (Missile Range 
Instrumentation Ships, 2001). The radars are collectively known as COBRA JUDY (Cobra 
Judy Radar System, n.d.). 


DISPLACEMENT 

17,015 LT 

LENGTH 

564 ft 

BEAM 

76 ft 

DRAET 

28 ft 

PROPULSION 

Steam, 7180.25 kW 


Table 3. USNS Observation Island Specifications (USNS Observation Island, 

2001) 


c. SBX 



Figure 5. Sea-Based X-Band Radar: The X-Band radar is under the large center 

dome (SBX, 2007). 


13 













The Sea-Based X-Band Radar (SBX) is unique for its physical design but 
also because it is part of the operational BMDS (Testing, 2009). The twin-hulled vessel 
is based on a fifth-generation self-propelled, semi-submersible oil drilling platform. The 
top of the dome is over 280 ft. above the keel. The powerful radar “can be positioned to 
cover any part of the globe” (SBX, 2007). The SBX is able to support BMDS testing; 
however, it is part of the operational BMDS. As part of the BMDS, it is designed to track 
and discriminate between a hostile warhead and possible decoys (SBX, 2007). 


DISPLACEMENT 

-50,000 T 

LENGTH 

390 ft 

BEAM 

240 ft 

DRAET 

133 ft 

PROFUSION 

4 Siemens 3401.387 kW Electric Motors 


Table 4. SBX specifications 


3. Pacific Tracker Concept 

The concept behind Pacific Tracker is to place a test range instrumentation 
quality radar, comparable to radars at USAKA, on a ship that can be positioned anywhere 
in the Pacific. Such flexibility would provide radar coverage on BMDS flight test 
scenarios that now have significant gaps due to the distance from land-based test range 
instrumentation radar assets. 

Data from such a radar would be valuable for multiple reasons. One is to 
characterize test events. For example, a radar can be used to determine the time- 
dependent position and motion of various test objects, associated hardware, and debris. 
The test objects may include the mock warhead of an offensive missile, possible decoys, 
and the interceptor kill vehicle (KV). Associated hardware may include spent rocket 
motors and hardware that is dispersed when rocket stages separate or test objects are 
deployed. Debris may include hot chunks of combustion by-products ejected from solid 
rocket motors or the fragments produced by an intercept event. While systems utilizing 
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Global Positioning Satellite (GPS) are able to produce data sufficiently accurate to be 
used to determine position and motion of many larger objects, many objects are too light 
or small to carry the equipment necessary to support transmitting GPS derived metric 
data. 

In order to meet the radar data collection requirements, MDA developed the X- 
Band Test Radar (XTR-1) with the intent to place the radar on a suitably sized ship. The 
XTR-1 is a dual, X and S, band radar with an 11m dish antenna. After the Pacific 
Tracker program was started, MDA/DTR decided to add the other Transportable 
Telemetry System (TTS-2) to Pacific Tracker. TTS-2 is a duplicate of the TTS-1 on 
Pacific Collector, also with dual 7m dishes. 

B. PACIFIC TRACKER PROJECT 

1. Mission 

The mission of the Sea-Based Platform Product Office (SBP) is to maintain, 
operate, and develop sea-based platforms to support MDA flight test activities. The SBP 
was initially formed in July 2007. The first two platforms in SBP’s portfolio were the 
telemetry collection ship Pacific Collector and the Mobile Launch Platform (MLP). The 
MLP is the ex-USS Tripoli, a former Iwo lima class amphibious assault ship. The 
primary function of the MLP is to serve as a launch platform for target missiles, similar 
to Scuds, for BMDS testing. The MLP is operated as a live-aboard barge and is towed by 
the former fleet tug, Narragansett. With the completion of the 24 August 2007 
Acquisition Strategy Panel (ASP), DTR assigned the development effort. Pacific 
Tracker, to the SBP. Responsibility for the ship passed from the Radar Product Branch 
to the SBP. 

The initial tasking of the SBP was to finalize ship selection and convert the 
selected ship to accommodate the XTR-1 radar. Once Beaver State was selected, the 
SBP had to complete five major efforts to convert Beaver State to Pacific Tracker. The 
five major efforts in the conversion process are: 1) Ship reactivation; 2) Modification of 
the ship to host the primary sensors, the adjunct systems, and the respective operators; 3) 
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Installation and integration of the primary sensors and adjunct systems; 4) Development, 
installation, and certification of the communications system; and 5) Coast Guard 
certification. This thesis is primarily centered on the utility of DoDAF for the ship 
modifications necessary to host the radar and the development of the communications 
system. The five major efforts are described in more detail below. 

1. Ship reactivation: Covers all actions to return the ship to sea-worthy 
condition. Based upon the ASP decision, the ships considered for conversions were all 
U.S. government-owned and mothballed in the inactive fleet. Mothballed is used here to 
describe measures taken to protect the ship and equipment from corrosion or 
deterioration. At a minimum, the preservation measures needed to be removed and the 
equipment returned to operating condition. Repairs would be needed to address 
deficiencies in the ship’s condition at the time of the mothballing and to address 
deficiencies resulting from deterioration that occurred while mothballed. Part of the ship 
selection process took into account the overall condition of the ships. 

2. Modification of the ship to host the primary sensors, the adjunct systems, 
and the respective operators: The ship selected for conversion would require 
modifications to accommodate the primary sensors, XTR-1 and TTS-2. Modifications 
necessary to support XTR-1 include: electrical distribution, a foundation for the radar 
antenna, and a control/computer room. Because the TTS-2 had already been built and the 
XTR was being assembled, the first approach was to have the XTR and TTS programs 
develop respective interface control documents (ICDs). Then the ship modifications 
would be designed to match the ICDs. 

This was the approach taken for installing the TTS-1 temporarily on the MLP and 
then permanently on Pacific Collector. The TTS was designed to be a self-sufficient 
system needing only a relatively flat piece of land or deck to sit on. It had its own power 
system, SATCOM system, control room, and antenna base. This was not the case with 
the XTR-1. XTR-1 had requirements for power, SATCOM, control room, and antenna 
base. The XTR-1 could not simply be bolted on the ship. Significant changes had to be 
made to the ship to accommodate the XTR-1. 
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3. Installation and integration of the primary sensors and adjunct systems: 
This phase is when the sensors are brought to the ship and installed. It also includes the 
time necessary to restore the sensors to working condition once installed on Pacific 
Tracker. 

4. Development, installation, and accreditation of the communications 
system: Initially the communication system was seen to be part of the XTR; however, 
with the addition of the TTS-2, this effort shifted to SBP to work. The initial concept 
primarily centered on test range communications and data transmission. As requirements 
for test range communications and data transmission were developed, requirements 
necessary to support XTR and TTS operations and maintenance surfaced. Accreditation 
of the communication system also became an issue because the Tracker had to interface 
with other DoD assets on the Global Information Grid (GIG). 

5. Coast Guard (CG) certification: Prior to a ship being authorized to sail, it 
must be in a condition that meets Coast Guard regulations. The CG certification process 
generally consists of a series of inspections by the CG or the American Bureau of 
Shipping (ABS). “A tax-exempt non-governmental organization (NGO), ABS has been 
commissioned by the U.S. government and the USCG to act in many maritime matters 
that relate directly to the safety of life and property at sea” (ABS Fact Sheet, 2005). 

2. Organization 

The SBP at the start of the project consisted of two individuals: the government 
project manager and one contractor employee. The project manager had experience with 
leading prior MDA test asset development efforts. These previous efforts were focused 
on the development of an infrared (IR) imaging sensor and extensive modification of 
aircraft to host the new IR sensor. The contractor employee, a retired Navy skipper, had 
extensive experience with ships. The organization was typical of project management in 
that the Pacific Tracker Project Manager (PTPM) was not anybody’s supervisor and had 
almost no formal contractual control. He was able to restrict the flow of money; 
however, that was only the coarsest form of control. The PTPM provided funding 
directly to three organizations: Johns Hopkins University/Applied Physics Laboratory 
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(JHU/APL), NSWC Corona Division, and MARAD HQ. The bulk of the funding, 
roughly 97%, went to MARAD. MARAD and NSWC received funds via Military 
Interdepartmental Purchase Request (MIPR). MDA had a contract with JHU/APL, and 
the PTPM was the task manager for that contract. 



Figure 6. Organization of the Pacific Tracker and major sensors projects. 


The PTPM assigned JHU/APL to provide detailed engineering analysis, as 
needed, and to provide systems engineering to support to the Pacific Tracker 
development efforts. The Radar Development Branch selected NSWC Corona to develop 
the communications system for the XTR-1 mission equipment. Corona was experienced 
with integrating SATCOM with MDA test assets. Corona had developed the SATCOM 
system linking TTS-1 and TTS-2 and successfully revamped the SATCOM on the MLP 
to name two projects. MARAD was assigned to make recommendations for the ship 
selection; to re-activate the ship; to modify the ship; and to gain CG certification. 

3. Acquisition Approach 

MDA considered several approaches for acquiring a ship to become Pacific 

Tracker. Among the approaches considered were a new acquisition—designing and 
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building a new special purpose ship; drawing a ship from the U.S. Inactive Reserve Fleet 
(which is also sometimes referred to as the MAR AD option); or a lease arrangement with 
a ship owner/operator. MDA/DTR considered designing and building a special purpose 
ship and quickly deemed the expected costs to be too high based upon a recent Navy 
contract award. The Navy had recently selected the design and build new approach for 
its Cobra Judy replacement program. In 2006, the Navy made a “$I99M contract award 
for the design and construction” (VT Halter, 2006) of a new ship based upon the existing 
T-AGS 39 design. The $199M price tag for the Cobra Judy replacement far exceeded 
MDA’s budget for Pacific Tracker. MDA considered two options in more detail: 1) 
drawing a ship from the U.S. Inactive Reserve Fleet and 2) a lease arrangement with a 
ship owner and operator. 

The acquisition of Pacific Collector followed the approach of drawing a ship from 
the U.S. Inactive Reserve Fleet. Given the success of Pacific Collector, MDA embarked 
on the same approach with Pacific Tracker. While MARAD was conducting the initial 
assessment of available ships in the inactive reserve fleet for MDA, Edison Chouest (an 
offshore vessel services company) approached MDA with the Lease option. Edison 
Chouest proposed to modify one of their vessels to support XTR requirements and then 
operate the ship for MDA under a ten-year lease. Once MARAD had completed the 
initial assessment, MDA performed a business case analysis of the three options in the 
summer of 2007. The results are shown in Table 5. The Director, Test Resources 
presented these results to MDA’s Acquisition Strategy Panel (ASP) on 24 August 2007. 


Estimator 

Total Sttip Outlays (SM) 

FYOe 

FYC9 

fno 

FY11 

FY12 

nrn 

Total 

FYDP 

FYDP Savings 

V5. Lease l|$M) 

DOBE 

MARAD 

Options 

Beaver State 

127 

13.0 

21.4 

21 8 

222 

227 

113 8 

28.6 

Diamond State 

13.6 

16.1 

21.4 

21.9 

22.3 

22.8 

1171 

25.3 

Mew Sliip (8500 LTns} 

970 

148.8 

21.0 

21 6 

21 9 

224 

3326 


LeSSG < based or Edison Chousest} 

16,5 

24.1 

24 7 

25,2 

25,7 

26,2 

142,4 



Table 5. Projected costs by FYfor Pacific Tracker development and operation 


As shown in Table 5, MDA’s procurement group estimated MDA’s costs for the 
three approaches to develop and operate Pacific Collector. Additionally, within the 
MARAD option, two different ships were considered. DOBE estimated that the design, 
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conversion, and XTR integration would occur within FY08 and FY09. These estimates 
allowed time for the sensor integration but did not include costs for the XTR integration 
or operation. These costs were ineluded when the ASP previously considered and 
approved the XTR program independent of ship platform. The eosts for the remaining 
years are projected maintenance, berthing, and operation. The operational costs are based 
on eight data collection voyages. The duration of each voyage was assumed to be 21 
days. 

MDA’s procurement group analysis determined that the New Ship approaeh was 
the most costly approach by a wide margin and supported DTR’s early rejection. The 
Lease approach did not appear to offer any great advantage above the MARAD approach. 
The Lease approach had the higher initial cost, higher operational cost, and of course, the 
higher total eost. The Lease option Edison Chouest proposed possibly offered the 
advantage of fixed, known costs with the contractor assuming the risk. The fixed cost 
option was only possible if the requirements were fully known and not likely to change in 
a signifieant manner—an unlikely seenario for the Paeifie Traeker project. MARAD had 
concluded that two crane ships, Beaver State and Green Mountain State, were best suited 
to meet MDA requirements. Beaver State and Green Mountain State were similar though 
not identical ships and either one could meet the MDA requirement to host the XTR. The 
difference in projected cost for the conversion and activation phase of the program was 
driven by the differenee between the physieal eonditions of the two ships. Beaver State 
was judged by MARAD to be best in class. 

4. Technical Approach 

The teehnieal approaeh for the Paeifie Tracker program was largely determined 
by the aequisition deeision to pull a ship from the inaetive reserve and modify it to meet 
the requirements of hosting the XTR. At the ASP, some discussion was given to the 
ability of candidate ships to host a TTS. However, the ability to host the TTS was not 
identified as a formal requirement until after the ship selection. The formal requirement 
at the time of the ASP was to find a ship with the size and eleetrical power generation 
capability to accommodate only the XTR. 
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At the time of the ASP briefing, the technical approach had four major steps. The 
first step was for the XTR-1 developer, Massachusetts Institute of Technology Lincoln 
Laboratory, to produce an interface control document (ICD). “MIT Lincoln Laboratory 
is a federally funded research and development center chartered to apply advanced 
technology to problems of national security” (MIT/LL, n.d.). The second step was for 
naval architects, under contract to MARAD, to develop a design in accordance with the 
XTR-1 ICD. The third step was for a shipyard to make the modifications to the ship. 
The fourth step was for the XTR to be integrated on the ship, once the shipyard work was 
completed. As the program progressed, TTS-2 and the communications system were 
added to the effort. The steps for TTS and the communications system followed a path of 
requirements definition, design, modification, and installation similar to XTR-l. 

The first step of developing the ICD was expected to be straight forward for the 
developer. The XTR-1 was in a relatively advanced stage of development and it already 
was being fabricated. The XTR-1 ICD was expected to describe the interfaces between 
the radar and the ship as well as identify other requirements for space, electrical power, 
and cooling for the radar. 

Likewise, the second step was expected to be straight forward for the naval 
architects to produce a design to host the radar. It was envisioned that the naval 
architects would quickly produce a detailed design. There were three major components 
of the design: the electrical system, structural modifications, and machinery 
(predominantly a chilled water system to cool the radar). It was understood that the 
electrical system would have to be modified to allow the radar to draw power from either 
diesel generator. Structural modifications that included building out rooms such as office 
spaces and control and computer rooms were expected to be relatively simple. While a 
larger effort, even the structural modifications foundation for the XTR antenna was 
considered to be straight forward. It was thought the design of chilled water cooling 
system was largely a matter of selecting the correctly sized commercial system. 

Once the modification design was complete, the third step was to compete the 

modification work among interested shipyards and have the winning shipyard perform 

the modifications. The modifications would be coupled with dry-dock work in the 
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competitive package. The dry-dock work would be routine items necessary to activate 
the ship and meet regulatory requirements. After the shipyard completed the 
modifications and work in the dry-dock, the fourth step would be to install the XTR-1 on 
Pacific Tracker. 

5. Schedule and Milestones 

The initial schedule that was shown during the ASP briefing is shown in Figure 7. 
Figure 7 shows Pacific Tracker milestones in relation to upcoming FTGs. FTG is the 
designation for flight tests of the Ground-based Midcourse Defense (GMD) system. FTG 
scenarios include the Vandenberg to Kwajalein trajectories. The first milestone is the 
authority to proceed with ship acquisition. The date coincides with the ASP presentation 
on 24 August 2007. At that time, the XTR-1 schedule showed that the radar would be 
ready to install on the ship towards the end of FY 2008. The detail design work prior to 
entering into the shipyard was scheduled to begin September 2007 and run approximately 
six months to the end of February 2008. This allowed only six months for MIT/LL to 
produce an ICD and for MARAD to produce the detailed design to modify the ship to 
allow it to accept the XTR. The next six months were allotted to shipyard modifications 
of the vessel. Then another six months were allotted for the installation of the radar on 
the ship. After another month of sea trials. Pacific Tracker would be ready to support 
FTG-08. 
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Phase 

FY07 

FY08 

FY09 

FY10 

FY11 
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★ ★ 
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Figure 7. Schedule for the project presented at ASP by DTR 


6. Design Evolution History 

The design requirements for Pacific Tracker, and hence the corresponding design 
concepts, underwent significant changes as the project proceeded. A few significant 
milestones in the program are used to capture the then current design requirements and 
design concepts at those particular junctures. The first milestone will be the ASP 
meeting. Subsequent milestones will be SRR, CDR, and contract award. Between 
milestones, the design made significant changes due to requirement changes, improved 
understanding of requirements, and cost constraints. 

a. Acquisition Strategy Panel 

At the time of the ASP, MIT/LL had yet to develop its ICD. There was 
sufficient understanding of the requirements for electrical power and physical size to 
select a ship. However, those requirements were not sufficiently understood for the naval 
architects to begin a detailed modification design. Several months after the ASP, two 
additional major requirements were added to the program. First was the addition of TTS- 
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2 and the second was for XTR-1 to operate throughout a flight without loss of data, even 
with a prime power causality. The impacts of those requirements are discussed in more 
detail in the following section on the Systems Requirements Review. 

b. Systems Requirements Review 

At the SRR, options were presented for modifications to the ship to 
provide: mission equipment electrical power, MDA mission personnel berthing, TTS 
antenna placement, and the communications system. In this thesis, the term “mission 
equipment” is used to denote the equipment associated with the XTR, TTS, and 
communications system. Between the ASP and the SRR, there were two major changes 
to Pacific Tracker requirements. The first was the addition of the TTS. The second 
major change was the clarification of the requirement to supply reliable power to the 
mission equipment. The power requirement was now to have the mission equipment, 
including the radar on UPS backup, sufficient to power the system for 30 minutes. The 
addition of TTS to the ship added not only new requirements to support the installation of 
the TTS equipment but also placed additional demands on berthing, the communication 
system, and the electrical system. While the addition of TTS drove changes to the 
electrical design, the requirement to supply reliable electrical power to the mission 
equipment was the biggest driver. (The primary source of information for the systems 
requirements review section is the March 2008 Trade Studies presented by the PTPM at 
the SRR.) 

The overarching requirement for the electrical system is to reliably meet 
the mission equipment’s power demand throughout the flight event. Prior to the addition 
of TTS, the XTR ICD indicated it would draw about 1280 kVA, including 
communications, when it was radiating at full mission load. The TTS ICD indicated its 
load would be another 320 kVA. The resulting total mission equipment load would be 
1600 kVA. The power generation capability seemed to be more than enough to meet the 
mission equipment’s expected load. 
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System 

Total 

XTR-1 

1,265 kVA 

TTS-2 

320 kVA 

Comms 

15kVA 

Grand Total 

1,600 kVA 


Table 6. Power requirements based on XTR-1 and TTS ICDs 

Beaver State has the capability to generate 3900 kW. She has two 750 kW 
steam turbine generators and two 1200 kW diesel generators. After taking into account 
the ship’s expected load of about 600 kW, there would still be 3300 kW available to 
power the mission equipment. The power generation capability for the generators is 
expressed in kW; however, the load is expressed in kVA. A conversion is required to 
express the power and the load in the same units. The MARAD electrical design 
engineer selected a power factor of 0.8. Therefore, the 1600 kVA load converts to 1280 
kW. The addition of TTS increased the mission equipment’s load by 25%. However, the 
generation capability was well over two times the expected load. 

The “reliably...throughout the flight event’’ portion of the requirement 
produced a more significant impact than adding the TTS load. “Throughout the flight” 
meant from shortly before the first launch until the last splash. For ICBM intercept tests, 
this translates to a time period of about 30 minutes. The intent was for XTR, TTS, and 
the communications system to remain fully functional, that is with no loss of data, for 30 
minutes even if the respective primary power source was lost. MARAD developed three 
options to meet the power requirement: 1) Modify the switchboard so both diesel 
generators operate in parallel; 2) Add a third diesel generator; and 3) Add an 
uninterruptable power supply (UPS) sufficient to power all of the mission equipment for 
30 minutes of operations. 

Option 1, as shown in Figure 8, has the following features: 1) Lowest cost 
of the options considered; 2) If one steam turbine generator or one diesel generator fails 
(after missile launch), the UPS units will provide continuity of mission equipment power 
for 30 minutes; and 3) Failure of either a diesel generator or diesel generator switchboard 
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will not interrupt power to S and X-Band High Voltage Power Supplies (HVPS) and 
XTR Antenna Servo Motors. The major disadvantage is that it did not meet 
management’s desire to have all the mission equipment baeked up by a UPS. 
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Figure 8. MARAD’s power option 1 


Option 2, as shown in Figure 9, has the following features: 1) Failure of 
any diesel generator or diesel generator switchboard will not interrupt mission power. 
The remaining diesel generator can maintain mission power without having to rely on 
UPS units; 2) The mission power system is completely isolated from the ship’s power 
system. Disruptions in the ship’s power system will not affect mission operations; and 3) 
According to MARAD, a 1640 kW diesel generator was currently available from another 
MARAD activity. The disadvantages of this option are: 1) It is the most expensive of all 
the options; 2) It requires new auxiliary machinery room and associated support systems 
for the diesel generator installation and a new diesel generator switchboard; and 3) 
Additional engine room watch personnel would be required. 
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Figure 9. Power option 2 


Option 3, as seen in Figure 10, has the following features: 1) Failure of 
any (or both) diesel generator will not interrupt mission power for a minimum of 90 
minutes, and 2) The mission power system is completely isolated from the ship’s power 
system. Disruptions in the ship’s power system will not affect mission operations. The 
disadvantages of option 3 are: 1) It requires installing a new diesel generator switchboard 
and Mission Switchboard, and four 400 kVA UPS units; and 2) Different voltages of the 
ship’s service power system, 450 V, and Mission power systems, 480 V, prevent the 
capability to parallel systems. Significant modifications are necessary to permit 
paralleling to the ship’s service switchboard and SSTG governors; and 3) The UPS 
battery life expectancy will likely cause new batteries to be purchased every few years. 

DT management considered the power options and projected costs. After 
some additional discussion, DT management decided to relax the requirement for 100% 
UPS backup for all mission equipment. When the requirement was changed from 100% 
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UPS backup to 100% backup, option 1 became viable. This option uses one of the diesel 
generators as the primary power source and the other diesel generator as the back up 
power source for the radar transmitters. Additionally, option 1 uses UPS as the back up 
power source for the other mission equipment. DT management directed the program to 
proceed with refining option 1. 



Figure 10. SRR power option 3 

Options for berthing were also presented at the SRR. There are not 
enough berthing rooms onboard the ship to provide every member of the ship’s crew and 
MDA mission crew with a private room. If each member of the ship’s crew had a private 
room, there would only be enough state rooms to accommodate eight MDA personnel, 
not the currently expected 22-29 personnel. MARAD developed three options to 
accommodate additional personnel. The first option is to utilize the existing staterooms 
without building additional staterooms. The second option is to install 24 new single 
staterooms and utilize six single staterooms currently existing within the ship’s house. 
The third option was to install 30 new single staterooms. 
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The first option is to use the existing 22 single and 21 double staterooms 
without building additional staterooms. The ship’s crew requires 12 single staterooms for 
the licensed and senior unlicensed personnel. For the remaining unlicensed personnel, 
they will be assigned to 14 double staterooms. The remaining ten single and seven 
double staterooms would be assigned to MDA mission personnel. This would allow 
MDA to place 24 personnel onboard. 

There are a number of issues associated with these limits. The first issue 
is the use of only the existing staterooms severely constrains the staffing flexibility for 
both MDA and MARAD. MDA will be restricted to only 24, just two more than the 
lower limit. The ship’s crew will be limited to 40. Previously, when Beaver State was 
active, she steamed with a crew of 39. The size of the ship’s crew had yet to be 
determined. The improved viewing, because the large cranes will no longer restrict the 
view from the bridge, may reduce the crew size by three, according to MARAD. 
However, the added MDA mission crew will likely increase the required number in the 
steward department. These numbers do not account for gender. For example, if there 
were seven males and seven females in the MDA crew whose status would normally 
place them in a double room, only one odd male or odd female could be berthed but not 
both. The option of only using existing staterooms does have the advantage of having the 
lowest cost of the three options. 

The second option was to build accommodations on the main deck in front 
of the house. These new accommodations would provide 24 new single staterooms for 
MDA mission personnel. This option also called for MDA to utilize another six single 
staterooms in the house. This would have allowed space for 30 MDA mission people and 
allowed the ship’s crew to reach a level of 35 before having to double bunk anyone. This 
option met the requirements; however, it did place limits on MDA’s flexibility. The issue 
with this option and the third option was cost. MARAD’s cost estimate for building the 
24 new staterooms was $5M. 

The third option presented called for the building of 30 new staterooms for 

MDA mission personnel. This would have provided MDA with enough berthing to meet 

its expectations and no one on the ship’s crew would have to double up. There even 
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would have been some vacant rooms to allow for contingency or additional sensors. This 
option would provide better living conditions for high ops tempo and would provide the 
most flexibility for staffing the ship and the MDA mission systems. The down side was 
the cost. By MARAD’s estimate, the incremental cost was only $500k more for 30 
staterooms over the 24 stateroom plan. The recommendation was to go with option 3. 

The initial plan for the TTS-2 antenna installation was to place them on 
the hatch coamings in the open. This concept was very similar to how the TTS-1 
antennas are mounted on Pacific Collector. However, DT leadership clarified the TTS 
requirement to include radomes over the antennas. Leadership mandated the use of 
radomes in order to improve the lifecycle maintainability of the TTS-2’s antennas. The 
issue with the radomes was that nothing could be allowed to block visibility for the wheel 
house. The visibility requirement is “...the view of the sea surface is not obscured 
forward of the bow by more than the lesser of two ship lengths or 500 meters (1,640 feet) 
from dead ahead to 10 degrees on either side of the vessel. Within this arc of visibility 
any blind sector caused by cargo, cargo gear, or other permanent obstruction must not 
exceed 5 degrees.” (Construction and Arrangement, 2004). Even the introduction of the 
shortest feasibly sized radome would exceed the allowable limits of obstruction if placed 
on top of the hatch coaming. 

The TTS developer initially provided a radome design that called for a 
height of 42 ft. With further discussions and analysis the TTS developer and the naval 
architect determined the maximum feasible height for the radomes to be 37 ft. A height 
of 37 ft could be achieved; however, there would be regrets for the TTS operators. Even 
so, the 37’ tall radomes placed on the hatch coaming would have blocked the view from 
the bridge. Therefore, three options, in addition to the no radome option, were developed 
to explore methods to allow heights of 37, 39, and 42 feet. 

Three options were presented to meet the combined requirements for 
visibility from the bridge and protecting the antenna: 1) Limit the radomes to a height of 
37 feet; remove hatch coamings, and modify the ship’s main deck; 2) Limit the radomes 
to a height of 39 feet; raise the wheel house one level; and partially modify the ship’s 

deck; and 3) Raise the wheel house two levels; without modifications to the ship’s deck. 
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MARAD’s first option has the advantage of being the lowest cost option 
which would allow radomes of any size. Nevertheless, it would call for an estimated 
$2.4M to remove the hatch coamings and build deck inserts strong enough to support the 
TTS antennas. As shown in Figure 12, the front radome would still produce a partial 
obstruction. This obstruction, however, would be within the allowable limits. The 
forward antenna was brought as far aft as possible to maintain a required 60 ft separation 
between antennas. 

The second option would allow a greater separation between antennas and 
a radome height of 39 ft. It would have also only called for the removal of one hatch 
coaming and the corresponding deck insert. However, it called for the wheel house to be 
raised one level, approximately 8 ft. This may have seemed to be the compromise option; 
however, it was the costliest of the three. While it combined the advantages, higher 
radome height, and less steel work on the main deck, it also combined the cost of major 
steel work on the main deck and the cost of raising the wheel house. 
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Figure 12. TTS antenna and deck configuration for option 2 


The third option allowed for the full sized radomes, 42 ft, and it avoided 
major steel work on the main deck. No hatch coamings would have to be removed; 
however, the wheel house would now have to be raised two levels, or 16 ft. The cost for 
option 3 was estimated to be $5M. DT management directed that option 1 for the TTS 
antennas be implemented. 



The XTR and the TTS have requirements to receive and transmit data. 
For example, both systems will require the ability to receive and send pointing data in the 
form of an inter-range state vector (IRV). In addition, it is highly desirable to send 
processed data from the systems in real time as they track objects during the test event. 
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PTPM directed APL to conduct a study to determine the MDA mission requirements for 
communication. This study did not address the communication equipment needed for 
ship operations. Their summary conclusion is shown in Table 7. 


Pihase 

Direction 

Critical 

Medium* 

Low* 

P re-Miss ion 

Incoming 

193 

1745 

2355 

Outgoing 

175 

1668 

2750 

During Mission 

Incoming 

193 

1315 

2718 

Outgoing 

175 

4333 

6535 

Post-Mission 

Incoming 

45 

1038 

1918 

Outgoing 

45 

2373 

5348 

Pier Side 

Incoming 

0 

2238 

6048 

Outgoing 

0 

2238 

6048 


* Cumulative intals (include- higher priority treiffic) 


Table 7. APL summary conclusions for bandwidth requirements in kbs 

APL recognized that the communication traffic would change as the 
system progressed from one phase of the test cycle to the next. The direction of the 
traffic, whether incoming or outgoing, needs to be considered along with the priority of 
the traffic. The test event activity was split into four phases: Pre-Mission, During 
Mission, Post-Mission, and Pier Side. The term During Mission refers to the time frame 
beginning roughly eight hours prior to the beginning of the launch countdown until 
several minutes after the flight test event. Pre-Mission is the time frame between leaving 
the pier and the start of the During Mission phase. Post-Mission is the time between the 
end of the test event and the ship arriving back at Portland. Pier Side is the time when 
Pacific Tracker is berthed at home port. Incoming traffic means the data flow from shore 
to the sensors. Outgoing traffic means the data flow from the sensors to the shore. APL 
used three levels of priority: Critical, Medium, and Low. Critical priority traffic means 
the traffic critically necessary to achieve the primary test event objectives, relative to the 
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XTR and TTS. Examples of this type of traffic are the inter-range vectors used to cue 
sensor tracking. Without these tracking cues, the ability of the XTR and TTS to 
autonomously acquire and track a target is not assured. Medium priority traffic is needed 
to support a certain function. For example, Medium traffic would be providing real time 
data, such as video from the booster sent via telemetry or XTR console display to the test 
range or other sites. This could also include such general support as phone and fax 
traffic. Low priority traffic is useful to support a certain function. However, without this 
traffic, the function would still work. For example, Internet access may fall into this 
category. None of the sensors are dependent on the Internet to function correctly; 
however, access to the Internet for information may help the operations (Zheng, 2008). 

The existing communications equipment from TTS-2 includes three Fleet 
77 INMARSAT and one wideband Sea Tel 2.4 m dish. The TTS had been configured so 
that the critical data had two paths: the Fleet 77 INMARSATS and the Sea Tel. The 
medium and low priority traffic only followed over the Sea Tel. While this configuration 
was sufficient for TTS alone, it did not allow enough bandwidth for the TTS and XTR 
critical data. The PTPM presented three options to address the shortfall: 1) one Sea Tel 
and four INMARSATS; 2) two Sea Tel systems; 3) two Sea Tels and three INMARSATS. 
The first option called for purchasing additional Fleet 77 INMARSAT and integrating the 
one Sea Tel and four INMARSATS onto the Tracker. Option 2 called for purchasing a 
second Sea Tel and installing only the two Sea Tels. The third option called for the 
purchase of a second Sea Tel as in option 2; however, the three existing INMARSAT 
would also be installed as a tertiary backup for the systems. DT management directed 
option 2 be pursued. 


c. Preliminary Design Review 

At the PDR, MARAD showed some further details on the designs 
presented at the SRR, except for the electrical design. The general arrangement for the 
placement of XTR-1 and TTS-2 had not changed. However, as MARAD’s naval 
architects refined the designs, additional questions surfaced. Between the SRR and the 
PDR, the naval architects had taken a much closer look at the XTR-1 requirements for the 
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antenna foundation. Significant amount of discussion between the naval architects and 
the XTR-1 developers ensued to better understand the stated requirements. The naval 
architects initially approached the foundation design from a traditional mechanical load 
perspective, for example, determining what mechanical loads, weight, torque, and so 
forth must the foundation support. However, the specifications MIT/LL had provided 
were in terms of stiffness, and in particular, required the foundation not to conduct 
vibration, which would excite the natural resonance frequency of the XTR-1 antenna 
pedestal. 


d. Critical Design Review 

During the progression from the SRR to the CDR, the power requirements 
became better understood and the power margin shrank. The MARAD design team 
became more concerned about the margin. MARAD completed a load analysis. The 
load analysis determined there was still enough power; however, the predicted mission 
equipment load had significantly increased from the early indications. The predicted 
mission equipment load had increased so much the design for the power system had to be 
changed. The concept at the SRR was for the SSDGs to supply primary and backup 
power for the radar antenna servos and S and X band high power voltage power supplies. 
For simplicity in this section, the radar antenna servos and S and X band high power 
voltage power supplies are referred to as simply, “the radar.” The other mission 
equipment, TTS-2; XTR-1 control; communications equipment; and mission support 
equipment (cooling water, HVAC, lighting, and so forth), would be powered by the 
SSTGs with backup power being provided by the UPS and the other SSDG. (The 
primary source of information for the critical design review section is the Aug 2008 Post- 
CDR briefing presented by the PTPM to DT management following the CDR.) 
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Figure 14. One line diagram of the power generation and distribution system 

presented at the CDR 
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System 

Radar On 
Max kVA 

Radar Off 
Max kVA 

XTR-1 

Radar 

1,060 

- 

Technical 

145 

145 

Utility 

13 

13 

Total XTR-1 

1,218 

158 

TTS-2 

Technical 

169 

169 

Utility 

144 

144 

Total TTS-2 

313 

313 

Mission Support 

Chilled Water 

658 

434 

HVAC 

88 

88 

Diesel Load 

104 

- 

Total Mission Support 

850 

522 


Grand Total 

2,381 

993 


Table 8. MARAD’s load analysis results 


At the CDR, it was clear that the expected loads for the other mission 
equipment were too large for the SSTGs to supply when the radar was operating. The 
SSTGs could supply sufficient power to the other mission equipment when the radar was 
not in operation. By operating, it is meant that generating RF energy would either be 
transmitted or converted into heat in devices known as dummy loads. The cooling 
necessary while the radar is operating is too much for the SSTGs along with the other 
mission equipment. When the radar is in operation, both SSDGs are necessary for power. 
One SSDG is required to power the radar and one SSDG is required to power the other 
mission equipment. Now, when the power system is configured for radar operation, if 
the SSDG powering the radar fails, the other SSDG must shed the other mission 
equipment load and switch to power the radar. The other mission equipment has to rely 
on the UPS for power. In a similar fashion, when the power system is configured for 
radar operation and if the SSDG powering the other mission equipment were to fail, the 
other mission equipment has to rely on the UPS for power. In this case, the other SSDG 
would continue to power the radar. 
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Two other significant changes were made to the power system design. 
The size of the UPSs were increased and the utility power for the TTS shelters was 
moved off the Mission Support UPS and over to the SSTGs. The two 400 kVA UPSs in 
the SRR concept had to be increased to 750 kVA each. The maximum load on the clean 
power UPS was expected to be 336 kVA while the maximum load on the mission support 
UPS had grown to 745 k VA. The predicted load on the clean power UPS did not 
increase much from the SRR. The predicted load on the mission support UPS had a 
significant increase. In particular, the chilled water and HVAC were the biggest factors 
which drove the power requirements. Both UPSs did not have to increase to the 750 
kVA size. The clean UPS could have easily stayed at 400 kVA. However, the decision 
was made to keep the UPSs identical with the expectation of reducing the cost of critical 
spares that must be kept onboard the ship. One may note the total load is not evenly 
spread over the two UPSs. 

The load is not more evenly split because of the type of loads. The 
compressors and other equipment on the Mission Support UPS are considered to be fairly 
noisy. And, that equipment does not require clean power as the mission electronics will. 
The Mission Electronics UPS provides power conditioning for the equipment attached 
behind it from equipment attached on the front side. It protects the Mission Electronics 
from noisy loads such as the radar’s high power voltage power supplies and compressors. 
This is why the TTS utility power was not shifted over to the Mission Electronics UPS 
even though there is more than enough margin left on the Mission Electronics UPS to 
accommodate the TTS utility power. The TTS utility power was shifted off the Mission 
Support UPS because the predicted load on that UPS had grown so large. The load on 
the Mission Support UPS provided motivation to move the TTS utility power off that 
UPS and because the noisy equipment described as TTS Utility could produce problems 
for the equipment powered by the other UPS. Thus, the decision was made to instead 
shift the load in question to the SSTGs. 

This decision avoided the need to go to an even larger or third, smaller 
UPS. The decision also, however, made the mission equipment more dependent on the 
SSTGs. Table 8 indicates that both SSTGs are needed to fully supply utility power for 
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the TTS shelters. This leaves the TTS Utility equipment without an instantaneous source 
of backup power. Not providing TTS Utility equipment with instantaneous backup was 
judged to be acceptable for several reasons. The loss of HVAC and lighting does not 
instantaneously stop the TTS data collection. Depending on ambient temperature 
conditions, the TTS may be able to operate 30 minutes without HVAC. Analysis also 
indicated that the ship’s crew would be able to shed enough of the ship’s load to allow 
the TTS utility equipment to come back on line prior to degradation of the data 
collection. Because of the conservatism in calculating the predicted load, the second 
SSTG may not actually be needed. 

No new designs for the crew berthing were presented. After the SRR, 
MARAD evaluated several other options for adding additional rooms. None of the 
options resulted in a significant cost savings over what had been considered at the SRR. 
The number of staterooms for the MDA mission crew did not change; however, it was 
determined that three of the rooms that had been counted as single, because of how they 
had been previously used, were actually double staterooms. Therefore, the allowable 
number of MDA mission personnel increased by three and now stood at 27, just two less 
than the stated requirement of 29. 

e. Contract Award 

The work package in the bid request was consistent with the design at 
CDR. Only one bid was received. Because the cost of the bid was much higher than 
expected, the work package was reduced to fit into available funding. Of the items 
discussed in this thesis, the major design change was to place the TTS antennas on top of 
the hatch coamings. Several months after the shipyard work began, additional funding 
was identified, and the contract was modified to revert to the TTS placement per the CDR 
design. 
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III. REVIEW OF DODAF 


A. INTRODUCTION 

This chapter discusses the Department of Defense Architecture Framework 
(DoDAF). Except as otherwise cited, all quotes and figures in this chapter are taken from 
the DoD Architecture Framework Version 1.5 Volume I: Definitions and Guidelines 23 
April 2007. The term architecture is in common usage usually applies to the structure or 
appearance of a building. Because architecture is applied to more than buildings, it is 
important to establish what is meant by architecture. Architecture, in this paper, is the 
“structure of components, their relationships, and the principles and guidelines governing 
their design and evolution over time” (DoDAF Version 1.5 v I). With this definition, the 
architecture still applies to the form and function of buildings and also to such diverse 
entities such as software, organizations, and military systems. The Defense Science 
Board has determined that standardized architecture descriptions are vital for ensuring 
interoperable and cost effective military systems (USD(A&T), ASD(C3I), J6, 1997). 
“An architecture description is a representation of a defined domain, as of a current or 
future point in time, in terms of its component parts, how those parts function, the rules 
and constraints under which those parts function, and how those parts relate to each other 
and to the environment.” (DoDAF Version 1.5, v I) 

Interoperability describes how well entities function and work together. More 
formally, interoperability is defined as “The ability of systems, units, or forces to provide 
data, information, materiel, and services to and accept the same from other systems, units, 
or forces and to use the data, information, material, and services so exchanged to enable 
them to operate effectively together” (DAU Glossary). As competition for resources and 
complexity of systems increases, so does the need to make sure all of the pieces function 
and work together. The probability of extraneous or poorly integrated components 
increases with the system’s complexity. The DoD can ill afford the cost of inefficiencies 
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produced by extraneous or poorly integrated components. To help ensure interoperable 
and cost effective military systems, the DoD has established DoDAF to describe DoD 
system architectures. 

The DoDAF is an evolution of the 1997 Command, Control, Communications, 
Computers, Intelligence, Surveillance, and Reconnaissance (C4ISR) Architecture 
Framework. The DoDAF’s purpose is to provide guidance for describing warfighting 
operations and business operations and processes, not just C4SIR systems. The DoDAF 
does not provide guidance on how to construct or implement a specific architecture or 
how to develop and acquire systems. The framework provides rules, guidance, and 
product descriptions for developing and presenting architecture descriptions. The 
principal objective of the framework is to make sure architecture descriptions of DoD 
systems can be related and compared throughout DoD, across service and even multi¬ 
national boundaries. Common principles, assumptions, and terminology address this 
objective. The DoDAF specifies three views that combine to describe the architecture. 
The three are Operational View (OV), Systems View (SV), and Technical Standards 
View (TV). Figure 15 (DoDAF Version 1) illustrates the relationships between the three 
views. 


All-View 



Figure 15. Interrelationships among DoDAF views 
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B. OPERATIONAL VIEW 


The OV is a description of the mission, warfighting, and other entities that need to 
be supported by the system. It describes what is going on with the system in the field. 
The OV contains textual and graphical products that identify the elements, assigned 
operations, and information flow between elements. This view reveals requirements for 
capabilities and interoperability. OV descriptions are useful for DoD wide assessments 
to examine business processes, technology insertion, or doctrinal and policy implications, 
to name a few. 

Usually the OV of a system is doctrine-driven. However, outside forces can 
cause a system or organization to operate in a manner inconsistent with doctrine. In these 
cases, the OV can be very useful to determine if doctrine changes are in order or if the 
root cause is some other factor such as lack of supporting infrastructure or information. 
Ideally, an OV is independent of materiel. However, new technologies may influence or 
push elements, assigned operations, and information flow between elements. For this 
reason, some high-level SV products or data elements may be needed to support 
information in the OV products. 

C. SYSTEMS VIEW 

The SV describes the existing and future systems and physical interconnections 
that support the mission documented in the OV. As used in DoDAF, a system is defined 
as “any organized assembly of resources and procedures united and regulated by 
interaction or interdependence to accomplish a set of specific functions” (DoDAF 
Version 1.0). The SV is used to address specific systems. This can include current, 
developing, or conceptual technologies, depending on the purpose for developing the 
architecture. The level of detail in the SV will depend on the purpose for developing the 
architecture. Architectures are developed for a variety of reasons. DoDAF users may 
develop Systems Views to describe the system’s current state, to assist in transitioning to 
a new state, or to analyze future options. 
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D. TECHNICAL STANDARDS VIEW 


The DoDAF defines TV as the smallest set of rules overarching the interaction, 
interdependence, and arrangement of system parts or elements. This view is used to 
ensure that a system meets particular operational requirements. The TV provides the 
technical guidelines on which the engineering specifications are based, products are 
developed, and common building blocks are recognized. This view additionally 
augments the SV with forecasts of standard technology evolution. 

E. PRODUCTS 

The DoDAF also defines 29 architecture products, which are organized into All 
Views, OV, SV, and TV. Figure 16 provides a list of architecture products (DoDAF 
Version 1.5). The DoDAF Version 1.5 also provides specific guidance on which 
architecture products are applicable for various uses of architecture descriptions. This is 
shown in Table 2 (DoDAF Version 1.5). 
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Applicable 

View 

Framework 

Product 

Framework Product Name 

Net-Centric 

Extension 

General Description 

All View 

AV-1 

Overview and Summary Information 


Scope, purpose, intended users, environment depicted, 
analytical findings 

All View 

AV-2 

Integrated Dictionary 


Architecture data repository with definitions of all terms 
used in all products 

Operational 

OV-1 

High-Level Operational Concept Graphic 


High-level graphical/textual description of operational 
concept 

Operational 

OV-2 

Operational Node Connectivity 

Description 


Operational nodes, connectivity, and information 
exchange need lines between nodes 

Operational 

OV-3 

Operational Information Exchange Matrix 


Information exchanged between nodes and the relevant 
attributes of that exchange 

Operational 

OV-4 

Organizational Relationships Chart 


Organizational, role, or other relationships among 
organizations 

Operational 

OV-6 

Operational Activity Model 


Capabilities, operational activities, relationships among 
activities, inputs, and outputs; overlays can show cost, 
performing nodes, or other pertinent information 

Operational 

OV-6a 

Operational Rules Model 


One of three products used to describe operational 
activity—identifies business rules that constrain 
operation 

Operational 

OV-6b 

Operational State Transition Description 


One of three products used to describe operational 
activity—identifies business process responses to 
events 

Operational 

OV-6C 

Operational Event-Trace Description 


One of three products used to describe operational 
activity—traces actions in a scenario or sequence of 
events 

Operational 

OV-7 

Logical Data Model 

V' 

Documentation of the system data requirements and 
structural business process rules of the Operational 

View 

Systems 

and 

Services 

SV-1 

Systems Interface Description 

Services Interface Description 


Identification of systems nodes, systems, system items, 
services, and service items and their interconnections, 
within and between nodes 

Systems 

and 

Services 

SV-2 

Systems Communications Description 
Services Communications Description 


Systems nodes, systems, system items, services, and 
service items and their related communications lay- 
downs 

Systems 

and 

Services 

SV-3 

Systems-Systems Matrix 

Services-Systems Matrix 

Services-Services Matrix 


Relationships among systems and services in a given 
architecture; can be designed to show relationships of 
interest, e g., system-type interfaces, planned vs. 
existing interfaces, etc. 

Systems 

and 

Services 

SV-4a 

Systems Functionality Description 


Functions performed by systems and the system data 
flows among system functions 

Systems 

and 

Services 

SV-4b 

Services Functionality Description 


Functions performed by services and the service data 
flow among service functions 

Systems 

and 

Services 

SV-5a 

Operational Activity to Systems Function 
Traceability Matrix 


Mapping of system functions back to operational 
activities 

Systems 

and 

Services 

SV-5b 

Operational Activity to Systems 

Traceability Matrix 


Mapping of systems back to capabilities or operational 
activities 

Systems 

and 

Services 

SV-Sc 

Operational Activity to Services 

Traceability Matrix 


Mapping of services back to operational activities 

Systems 

and 

Services 

SV-6 

Systems Data Exchange Matrix 

Services Data Exchange Matrix 


Provides details of system or service data elements 
being exchanged between systems or services and the 
attributes of that exchange 
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Applicable 

View 

Framework 

Product 

Framework Product Name 

Net-Centric 

Extension 

General Description 

Systems 

and 

Services 

SV-7 

Systems Performance Parameters Matrix 
Services Performance Parameters Matrix 


Performance characteristics of Systems and Services 
View elements for the appropriate time frame(s) 

Systems 

and 

Services 

SV-8 

Systems Evolution Description 

Services Evolution Description 


Planned incremental steps toward migrating a suite of 
systems or services to a more efficient suite, or toward 
evolving a current system to a future implementation 

Systems 

and 

Services 

SV-9 

Systems Technology Forecast 

Services Technology Forecast 


Emerging technologies and software/hardware products 
that are expected to be available in a given set of time 
frames and that will affect future development of the 
architecture 

Systems 

and 

Services 

SV-10a 

Systems Rules Model 

Services Rules Model 


One of three products used to describe system and 
service functionality—identifies constraints that are 
imposed on systems/services functionality due to some 
aspect of systems design or implementation 

Systems 

and 

Services 

SV-10b 

Systems State Transition Description 
Services State Transition Description 


One of three products used to describe system and 
service functionality—identifies responses of a 
system/service to events 

Systems 

and 

Services 

SV-10C 

Systems Event-Trace Description 

Services Event-Trace Description 


One of three products used to describe system or 
service functionality—identifies system/service-specific 
refinements of critical sequences of events described in 
the Operational View 

Systems 

and 

Services 

SV-11 

Physical Schema 


Physical implementation of the Logical Data Model 
entities, e g., message formats, file structures, physical 
schema 


TV-1 

Technical Standards Profile 


Listing of standards that apply to Systems and Services 
View elements in a given architecture 


TV-2 

Technical Standards Forecast 


Description of emerging standards and potential impact 
on current Systems and Services View elements, within 
a set of time frames 


Figure 16. DoDAF Products 
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= Data Highly Applicable 
= Data is Often or Partially Applicable 
_ = Data is Usually Not Applicable 


Figure 17. Architecture Products and their Applicability 


F. DODAF SUMMARY 

Architecture is the “structure of components, their relationships, and the 

principles and guidelines governing their design and evolution over time.” An 

architecture description is a representation of a defined domain, as of a current or future 

point in time, in terms of its component parts, how those parts function, the rules and 

constraints under which those parts function, and how those parts relate to each other and 

to the environment.” To help ensure interoperable and cost effective military systems, 

the DoD has established DoDAF to describe DoD system architectures. The DoDAF is 

an evolution of the 1997 (C4ISR) Architecture Framework. The framework provides 

rules, guidance, and product descriptions for developing and presenting architecture 

descriptions. The DoDAF specifies three views that combine to describe the architecture. 

The three views are: Operational View (OV), Systems View (SV), and Technical 

Standards View (TV). Usually the OV of a system is doctrine-driven. The SV is used to 
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address specific systems. Architectures are developed for a variety of reasons. DoDAF 
users may develop Systems Views to describe the system’s current state, to assist in 
transitioning to a new state, or to analyze future options. The DoDAF defines TV as the 
smallest set of rules overarching the interaction, interdependence, and arrangement of 
system parts or elements. The DoDAF also defines 29 architecture products, which are 
organized into All Views, OV, SV, and TV. It is intended to allow architecture 
descriptions of DoD systems to be related and compared throughout DoD, across service 
and even multi-national boundaries. 
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IV. ANALYSIS OF THE APPLICABILITY OF DODAF TO THE 
PACIFIC TRACKER CONVERSION 

A. INTRODUCTION 

In this chapter, the utility of applying DoDAF to the PT program is analyzed. An 
architecture for the PT is described, and the possible impact of the architecture on the 
course of the program is considered. The purpose of the PT is to fill radar gaps in a wide 
variety of MDA flight tests across the Pacific. The effort to convert a ship to host an 
instrumentation radar and telemetry system was conducted without the use of DoDAF. In 
this chapter, an architecture that could have been produced and utilized to support the 
conversion effort is described. The PT architecture consists of nine DoDAF data 
products. The data products are as follows: AV-1, OV-1-5, SV-1, 2, and 6. Each of these 
data products is subjectively assessed for possible impacts on the program’s course. 

B. SELECTED BEA VER STATE CONVERSION DODAF PRODUCTS 

1. All View-1 Overview and Summary Information 

AV-1 is a text document used to provide information: 1) to identify the project; 2) 
the scope of the architecture; 3) its purpose and viewpoint; 4) its context, and 5) the tools 
and file formats used. AV-1 for the conversion is provided as a PowerPoint slide in 
Figure 18. 
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AV-1 Overview and Summary Information 


• Architecture Project Identification 

- Name: Beaver State conversion to Pacific Tracker 

- Architect: Mike Lash 

- Organization Deveioping the Architecture: MDA/DTR Sea Based Piatforms 

- Approvai Authority: TBD 

- Date Compieted: Version 1.1 19 May 2009 

- Levei of Effort and Projected Costs to Deveiop the Architecture: 200 hours 

• Scope: Architecture View(s) and Products Identification 

- Views and Products Deveioped: AV 1; OV 1-5, SV 1-2, 6 

- Time Frames Addressed: Current and End State 

- Organizations invoived: MDA/DTR, MARAD HQ, MARAD Western Region, MiT/LL, WSMR, MDO, 
JHU/APL, interocean American Shipping (iAS), NAVAiR, NSWC-Corona 

• Purpose and Viewpoint 

- Purpose, Analysis, Questions to be Answered by analysis of the Architecture: 

- Assess whether incorporating DoDAF would have improved the way the project was done. 

- What DoDAF products might have been produced to support the project? 

- How may have the DoDAF methodology changed the way the project was done? 

- Would the DoDAF methodology have been useful to the project or be useful to future MDA test asset 
development projects? 

- From Whose Viewpoint the Architecture is Developed: Program Manager/ Systems Engineer 

• Context 

- Mission: Conversion of Beaver State to Host XTR-1 and TTS-2 

- Doctrine, Goals, Vision: Produce a cost effective range instrumentation ship which will reduce BMDS 
dependence on land based radars 

- Rules, Criteria, and Conventions Followed: Must be compatible with other range assets 

- Tasking for Architecture Project and Linkages to Other Architectures: None 

• Tools and File Formats Used: Microsoft Office 2003 


Figure 18. Pacific Tracker Overview and Summary Information 


2. OV-1 High Level Concept Description 

OV-1 provides a graphical high level description of the concept. As shown in 
Figure 19, the Pacific Tracker is designed to: collect and record X & S band radar data 
and S band telemetry data on BMDS flight test events; send and receive data via 
SATCOM to and from other test participations; and to operate in the BOA. The graphic 
shows the XTR-1 antenna mounted behind the house and the twin TTS-2 antennas 
mounted in front of the house. The graphic depicts the two sensors collecting data on an 
interceptor and target missile. Also, as depicted other test participants may be other sea 
base systems, airborne sensors, and land-based systems. 
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OV-1 High Level Concept Description 



* The Pacific Tracker is designed to 

- Collect and record X & S band radar and S band TM on BMDS flight test 
events 

- Send/receive data real time via SATCOM to/from other test participants 

- Operate from the broad ocean area (BOA) 


Figure 19. Pacific Tracker High Level Concept Description 


3. OV-2 Operational Node Connectivity 

OV-2, in Figure 20, provides a description of the operational node connectivity. 
A drawing of the physical system passing data to actors who are part of the test event is 
used. It seems that using such a drawing is a poor practice. The drawing can add to the 
confusion caused by having a physical system, the ship, the XTR-1, and TTS-2, called 
the Pacific Tracker; a project named Pacific Tracker; and a ship named Pacific Tracker. 
In the early phases of a test event, the physical system is not being used to exchange 
information with the Test Resource Manager (TRM). Test planners with the Pacific 
Tracker program will be exchanging information with the TRM by standard methods of 
business communications, for example, email and phone conversations. 
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The upper part of Figure 20 is taken from MDA Directive 3002.03 dated 15 
January 2009. It shows the five phases of a BMDS test event: 1) Requirements, 2) 
Planning and Design, 3) Readiness, 4) Execution, and 5) Analysis and Reporting. In the 
first three phases and the first part of the fourth phase, the information flowing through 
the TRM to the Pacific Tracker program is data requirements, test event description, and 
status. Questions about capabilities and status will also flow to the PT program. Often, 
capability questions will start with “Can you...” or “What if...” The information that 
will be exchanged between the Pacific Tracker program and the test event via the TRM 
will tend to become more detailed as time progresses. The initial information will start 
with general information about data requirements and general information on the what, 
where, and when of the test scenario. As the level of detail of the data collection 
requirements and scenario information increases, so too will the level of detail in the 
plans the PT program provides back to the test event via the TRM. During the first three 
phases and the first part of the fourth phase, the PT system will not be used to support the 
test event. 
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OV-2 Operational Node Connectivity 
Description 


BMDS TEST EVENT 



1*4 Mr* HM IlBI* WJWT -. 




(|&T|]npiii 
D iinii] 


ag^ 


Count Status 
Pointing Data 


Flight 

Test Event 




* BMDS Test Events progress from start to completion through the 
five phases 

* The PT program supports BMDS Test Event through ail five phases 

* The PT system supports the Execution phase 


Figure 20. OV-2 Operational Node Connectivity Description 


For the design of the PT system, the node connectivity of the earlier phases is not 
as important as the node connectivity when the PT system is used. Current planning calls 
for the Pacific Tracker system to begin supporting a test event towards the later part of 
the fourth phase. Execution. A dockside communications demonstration is expected to 
be generally the first time the system will be used to support a given test. Then, 
sometime after the communications demonstration, the system will be put to sea. 
However, depending upon the distance between test support positions and the time 
between test events, the system may already be at sea during the first communications 
demonstration. The communications demonstration not only demonstrates that the 
communications links for the live flight test are operational; it also demonstrates the 
participant systems’ ability to process simulated data. 
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The live flight test is depicted by the maroon star in Figure 20 labeled “Test 
Event.” For purposes of this thesis, the live flight test is the time that the missiles are in 
flight. During the live flight test, test data and voice communications will be exchanged 
between the test event via the range and the PT program using the PT system in real time. 
Figures 21 and 22 depict the node connectivity for test data and for voice communication, 
respectively. Figure 21 is the OV-2 that depicts the operational node connectivity for 
digital data passed between the electronic systems. Figure 22 is the OV-2 that depicts the 
operational node connectivity for voice communications. 

Figure 21 shows connectivity between the range and the two sensors, XTR-1 and 
TTS-2. There is also connectivity between the sensors and the Pacific Tracker Lead 
(PTL) Situational Awareness Display (SAD). The type of information sent from the 
range to the sensors is the countdown clock and track data on selected test objects. Track 
data on the objects being tracked by the sensors are sent to each other and the range. 
Other selected data collected by the sensors are also sent to the range. The sensors will 
also send track data to the PTL SAD along with other real time data to keep the PTL 
advised of the sensors’ respective status. 
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Figure 21. OV-2 Operational Node Connectivity Description Test Event Data 

In addition to digital data passed between electronic systems, verbal 
communications will occur between individuals participating in the mission. Figure 22 is 
the OV-2 description for the verbal node connectivity during the test event. There will be 
other voice nets onboard and off board than what is shown in Figure 22. Figure 22 shows 
the primary voice nets. The intent is to have the PTL be the primary human interface 
with the range officer. One reason to do this is to reduce the task loading on the 
respective sensor leads. It is also intended that only one person, the PTL, is providing 
direction, requests, and questions to the ship’s master. 
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Figure 22. OV-2 Operational Node Connectivity Description Test Event Voice 

4 OV-3 Operational Information Exchange Matrix 

OV-3 is a tabular representation of operational information exchange along the 
need lines as depicted in OV-2. Figures 23 and 24 present more detailed listings of 
information exchanged between nodes and some information on what the receiving node 
does with the information. The format for Figures 23 and 24 was taken from Maj Hartt’s 
executive seminar on DoDAF (n.d.). DoDAF 1.5 volume II provides an OV-3 template 
which allows for more details to be provided in the matrix. However, Maj Hartt’s 
template addresses the key needs associated with the PT system (DoD Architecture 
Framework Executive Seminar, n.d.). 
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OV-3 Operational Information Exchange Matrix 

Test Event Data 


Need 

Line 

Information 

Exchange 

Sending 

Node 

Sending 

Activity 

Receiving 

Node 

Receiving 

Activity 

Type 

Range to PT 

Countdown 

Clock 

Range 

Syncing 
Countdown 
activities to 

countdown 

clock 

PT 

Cueing for 
mission 

execution 

Digital 

Range to XTR-1 
&TTS 

Test Object(s) 
Position 

Range 

Processing 
position 
information 
from various 

sources and 
disemenation 

XTR-1, TTS 

Cueing for 
pointing 
antennas and 
setting range 
gate 

Digital/ 

Interstate Range 
Vector 

XTR-1 & TTS to 

range 

Test Object(s) 
Position 

XTR-1 & TTS 

Processing 

position 

information 

from XTR-1 & 
TM and 

disemenation 

Range 

Processing 

position 

information 

from various 

sources and 
disemenation 

Digital/ 

Interstate Range 
Vector 

XTR-1 to PTL 

SAD 

XTR-1 mode, 
antenna 

position, display 
data 

XTR-1 

XTR-1 operation 

PTL SAD 

Situational 

awareness 

Digital 

TTS to PTL SAD 

TTS antenna 
position, TM 
data 

TTS 

TTS operation 

PTL SAD 

Situational 

awareness 

Digital 

XTR-1 to Range 

Radar display 
datat 

XTR-1 

XTR-1 operation 

Range 

Situational 

awareness 

Digital 

TTS to Range 

Processed TM 
data 

TTS 

TTS operation 
and data 
processing 

Range 

Situational 

awareness 

Digital 


Figure 23. 


OV-3 Operational Information Exchange Matrix with Test Event Data 
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OV-3 Operational Information Exchange Matrix 

Test Event Voice 





Need 

Line 

Information 

Exchange 

Sending 

Node 

Sending 

Activity 

Receiving 

Node 

Receiving 

Activity 

Type 


PTL to RO 

Tracker Status 

PTL 

Collect and 
disseminate 
Tracker (XTR-1, 
TTS, ship, and 
comm status) 

RO 

Collect and 
disseminate 
participant 
status 

Voice, external 
range net 

RO to PTL 

Range Count 

RO 

Conduct 

Countdown 

PTL 

Execute mission 
plan or make 
adjustment 
accordingly 

Voice, external 
range net 

PTL to Ship's 
Master 

Request 
Heading, 
Speed, Power 
Transfer, Status, 
Radiate 

PTL 

Execute mission 
plann or make 
adjustment 

Ship's Master 

Approve and 
implement or 
disapprove and 
explain 

Voice, internal 
phone 

Ship's Master to 
PTL 

Acknowledge 
Heading, 
Speed, Power 
Transfer. 
SOLAS 
information 

Ship's Master 

Adjust heading 
and speed, 
coordinate 
power transfer, 
stautsand 
SOLAS 

PTL 

Inform TTSL & 

XRTL 

Voice, internal 
phone 

PTL to XTRL 

Changes to 
Heading, 
Speed, Power 

PTL 

Disseminate 
changes to 
heading speed, 
power 

XTRL 

Respond 

accordingly 

Voice, internal 

XTRL to PTL 

Request 
Heading, 
Speed, Power 
Transfer 

XTRL 

Execute mission 
plann or make 
adjustment 

PTL 

Decide to relay 
to ship's master 
or not 

Voice, internal 
net 

PTL to TTSL 

Changes to 
Heading, 
Speed, Power 

PTL 

Disseminate 
changes to 
heading speed, 
power 

TTSL 

Respond 

accordingly 

Voice, internal 
net 

TTSL to PTL 

Heading, Speed 

TTSL 

Execute mission 
plann or make 
adjustment 

PTL 

Decide to relay 
to ship's master 
or not 

Voice, internal 


Figure 24. OV-3 Operational Information Exchange Matrix with Test Event Voice 

5 OV-4 Organizational Relationships 

If DoDAF had been used, it is likely that the current and end state organizational 
relationships would have been considered. The organizational relations evolved over the 
course of the program. To keep the architecture description current, OV-4 may have 
been updated from time to time. Here, OV-4 is produced relative to two junctures in the 
program: the ASP and the shipyard contract award. Figure 25 shows the organizational 
relationships at the time of the ASP. Figure 26 shows the relationships at the time of the 
contract award. OV-4 descriptions are also produced for possible end state 
configurations. Figure 27 reflects possible overall program relationships, and Figure 28 
shows possible relationships during flight test operations on the ship. 
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Figure 25 shows the relationships between the three branches, also called product 
offices, within the Test Resource Infrastructure Division (DTRI) involved with the 
Pacific Tracker program. Flight Safety and Telemetry, Sea-Based Platforms, and the 
Radar Development Branches. At the time of the ASP, the TM and Flight Safety branch 
had already developed TTS-1 & 2. This branch also oversaw the TTS-1 operations on 
the Pacific Collector and TTS-2 operations on land. The TTS was developed and 
operated by a group from WSMR. WSMR had selected NSWC-Corona to develop and 
operate its SATCOM system. The SBP Branch was charged with the responsibility to 
select and modify a ship to meet XTR-1 requirements. MAR AD was the executing agent 
for SBS. MARAD Western Region, at the direction of MARAD HQ, engaged a firm, ICI 
and its sub contractor MDO, to perform the naval architecting. MIT/LL was still in the 
process of developing the XTR-1 for the RD Branch. The RD arranged for the targets 
group from NAVAIR, Naval Air Station, Pawtuxet River to be the EA for the radar 
operation through its contractor Computer Sciences Corporation (CSC). It was planned 
for CSC to provide the permanent crew for the XTR-1. The RD branch also went to 
NSWC Corona group to develop and operate the STACOM system. At the time of the 
ASP, the three branches were organizationally on the same hierarchical level; however, 
SBP was tasked to accommodate RD/XTR-1 requirements and soon after the ASP, 
TM&Safety/TTS requirements were added to the tasking. 
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OV-4 Organizational Relationships 
Development 
(ASP Aug 2007) 



Figure 25. OV-4 Organizational Relationships August 2007 

By the time of the shipyard contract award, the hierarchy among the DTRI 
branches had changed. Figure 26 reflects the organization at the time of the shipyard 
contract award. Most of the organizations were still involved; however, there were 
several significant changes. The TM/Safety Office was brought within SBP so that the 
vessels and on board instrumentation would have common management within DTRI. 
SBP also took over responsibility for the communications system and brought the Corona 
group within the SBP purview. MARAD was able to reduce one contract by moving the 
Naval Architects subcontract under IAS. By the time the contract was awarded, SBP was 
also assigned the lead systems engineering role for the Pacific Tracker program, a 
significantly different role than modifying a ship to meet XTR-1 requirements. 
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OV-4 Organizational Relationships 
Development 

(Shipyard contract award Jan 2007) 



Figure 26. OV-4 Organizational Relationships January 2009 

Once XTR-1 development is completed, current plans call for responsibility for 
XTR-1 to be brought within SBP, just as the TM/Safety Office was brought within SBP 
so that the vessels and on board instrumentation would have common management within 
DTRI. As shown in Figure 27, a possible end state is for the SBP office to be relative to 
only the Pacific Tracker program. Organizational relationships are not shown for the 
other systems: Pacific Collector, KMRSS/Worthy, and the MLP, within SBP. Figure 27 
also shows how SBP will have to interface directly with at least five different 
organizations in order to manage the Pacific Tracker program. 
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OV-4 Organizational Relationships 
Possible End State Pacific Tracker 



Figure 27. OV-4 Organizational Relationships, Possible End State Pacific Tracker 

As part of the management of the Pacific Tracker program, the organization 
relationships onboard Pacific Tracker when at sea also needs to be considered. Figure 28 
shows a possible configuration for the system at sea. While MARAD and NAVAIR will 
not disappear while Pacific Tracker is at sea, their roles will become more indirect, very 
much like SBP. It is not that the structure shown in Figure 27 goes away. It is that only a 
subset of the actors relative to the overall program goes to sea. The PTL will have more 
direct contact with the Range than she will have with the SBP. The thought behind 
Figure 28 is that the PTL will be responsible for top level direction and coordination of 
the XTRL, TTSL, communications, and the ship. To this end, the PTL is in the 
leadership position over the Pacific Tracker system and people deployed for the flight 
test. The ship’s master is shown in a subordinate role to the PTL in relation to flight test 
support. The intent is to reflect the overall mission of flight test support. The master has 
supremacy in matters related to Safety of Life at Sea (SOLAS) and the safety of Pacific 
Tracker. 
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OV-4 Organizational Relationships 
Possible End State Pacific Tracker 
(Flight Test Operations^ 



Figure 28. OV-4 Organizational Relationships, Possible End State Pacific Tracker 

(Flight Test Operations) 

6 OV-5 Operational Activity Model 

The next view is OV-5, Operational Activity Model. The model shown in Figure 
29 closely matches the example in Maj Hartt’s DoDAF executive seminar presentation 
(n.d.). In his example, Maj Hartt was using an aerospace operations center (AOC) as an 
example. On first consideration, a missile range instrumentation ship does not resemble 
an AOC in form or function. However, in term s of the process, there is much overlap. 
Both the AOC and test assets can go through a planning - execution - maintenance cycle. 
The first step is to obtain information necessary for planning. Two general types of 
information entering the program are shown at the top left: Requirements and Test Event 
Information. 
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The requirements are listed first. The second type of information is test event 
related information. Requirements may be data collection requirements or regulatory 
requirements. Data collection requirements will, in part, describe what data will be 
collected on which test objects, for example. Regulatory requirements are laws, licenses, 
and restrictions applicable to any part of the Pacific Tracker operation. Test information 
is any information that may affect planning. Test information may or may not be directly 
related to the flight test. For example, information on launch windows is directly related 
to the test. Weather information, while not directly related to the test, can certainly affect 
data collection plans. 

The BMDS test support planning group will take this information and produce a 
plan for the BMDS test execution group to utilize in order to conduct the mission. The 
planning group will also pass along other relevant information to the test support. The 
execution cell will support the test in accordance to the accepted plan. The execution 
group will provide reports and data outside of the PT. That group will also provide 
information to the maintenance group on the performance of the various systems. The 
maintenance group will provide information on the condition of the PT. This generic 
scenario can be applied to TTS, the radar, and even the ship. It has been my experience, 
depending on the level of specialization required, that the individual may find herself 
operating in one or more of the identified groups. 
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Another example of an operational activity model is shown. Figure 30 illustrates 
some of the activities associated with execution during the actual test event. The time 
period covered in this mode may range between 5 hours to 36 hours. The starting event 
is the start of the count and the receipt of the quick look report is used as the terminating 
event. The systems leads will ready their respective systems and provide reports to the 
PTL. The PTL will in turn provide these status reports to the range on a predetermined 
schedule that is usually called out in the script for the count down activities. Depending 
on the status of the various test participations, the range will have a decision to make on 
adjusting the count or proceeding as scheduled. The launch begins the data flow to the 
PT and other systems involved with the flight test. Pointing information in the form of 
inter range state vectors will flow to the radar and TM systems. The instrumentation 
leads with then attempt to establish track on their respective items of interest as 
established by the data collection plan. Once the systems are in track and collecting data, 
the systems will flow pointing information to each other and back to the range. The 
activity of collecting, recording, flowing data will continue until loss of signal (LOS). 
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After the data collection has ended, the execution team will produce a quick look, or 
multiple quick look reports. Reporting times can vary from program to program. The 
initial report, usually provided within an hour, is a qualitative assessment of how the 
system performed. Specific data products are requested to support the Quick Look 
Report, which is generally due within the first 24 to 48 hours. 


OV-5 Operational Activity Model 

(Execution) 



■► (Data Flow) -► (Activity Flow) 


Figure 30. OV-5 Operational Activity during test execution 

7 SV-1 System Interface Description 

OV-2 provided a description of nodes or parts of the system that are connected to 
other parts of the system. SV-1 System Interface Description is found in Figure 31. It 
depicts two types of interfaces, voice and data. Voice interfaces are used between 
persons on Pacific Tracker and person(s) on the range. It also indicates data interfaces 
between systems on Pacific Tracker and the range. As shown in Figure 31, the XTRL, 
the TTSL, and the PTL will have voice communications amongst themselves and the 
range. In addition, the ship’s master will have voice communications with the PTL. The 
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XTR-1, TTS, and the range will be connected in such a manner as to allow the 
transmission and receipt of data to and from each other. The PTL Situational Awareness 
display is able to receive data from XTR-1, TTS, and the range. 


SV-1 System Interface Description (Test Event) 



Figure 31. SV-1 System Interface Description 

8. SV-2 Systems and Services Communications Description and SV-6 
Systems Services Data Exchange Matrix 

In Figure 32, SV-2, a different graphical depiction is used to provide more 

detailed information on the communications systems used to connect people and systems. 

Figure 32 in and of itself does not provide much additional data over what was depicted 

in SV-1, Figure 31. The SV-2 produced must be coupled with SV-6, Figure 33, to get 

more detailed information on the communications services. The SV-6 matrix contains 

information on the medium, bandwidth, and data format. Both of these products are 

capable of showing more information on the communications system than what is 

presented in this thesis. These products were intentionally left underdeveloped for 

reasons that will be discussed in the next section of this chapter. 
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SV-6 System Services Data Exchange Matrix 
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Figure 33. SV-6 Services Exchange Matrix 


C CONCLUSIONS: POSSIBLE IMPACT OF DODAF ON THE PACIFIC 
TRACKER PROGRAM 

In my estimation, on the whole, had DoDAF been used, there might have been 
improvements to the program. However, these improvements would have been marginal. 
None would have significantly changed the course of the effort, though at times some of 
the products could have been useful. In particular, the operational views seemed to have 
the most potential utility. The system views appear as if they would have provided very 
little utility. If one considers the reasons for using DoDAF, one could have predicted its 
limited usefulness to the Pacific Tracker project. 

Chapter II provided a description of some other ship systems used in missile 
defense testing and a description of the design evolution major modifications to the ship. 
The description of the other ship systems was provided in order to familiarize the reader 
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with existing systems or in other terms, familiarize the reader with what has been done 
before. The description of the evolution of four major elements, mission equipment 
electrical power, MDA mission personnel berthing, TTS antenna placement, and the 
communications system was provided to give the reader a sense of the major design 
issues confronting the conversion project. Three of the major design efforts, electrical 
power system, berthing, and placement of the TTS antennas with radomes have little or 
nothing to do with interoperability. Of the four major design efforts only the 
communications system is significant to interoperability. 

According to the Defense Science Board, the major reasons for using a 
standardized architecture description, such as DoDAF, is to ensure interoperable and cost 
effective military systems (USD(A&T), ASD(C3I), J6, 1997). To paraphrase the DAU 
Glossary, interoperability for the Pacific Tracker system is its ability to provide data and 
information and accept the same from the Range and other test assets and to use the data 
and information to enable them to operate effectively together. The Pacific Tracker’s 
communication system is an integral part of its interoperability. Since DoDAF grew out 
of the 1997 Command, Control, Communications, Computers, Intelligence, Surveillance, 
and Reconnaissance (C4ISR) Architecture Framework (DoDAF Version 1.5 v I), one 
might conclude that DoDAF would have been very useful. If this had been the first time 
a SATCOM system was developed to interface with a test range, the preceding 
conclusion would likely be valid. For the Pacific Tracker, it is not a valid conclusion 
because it has been done before. It has been done before on Pacific Collector, 
KMRSSlWorthy, and the MLP. While the co mm unication system on Pacific Tracker is 
more complex than the other three, it is not much more complex. With the two sensors, it 
is more of a question of bandwidth than complexity. 

In order for the Pacific Tracker system to be interoperable with the Ranges, the 
two sensors have to be interoperable with the Ranges as well as the communication 
system. Here again, it has been done before. The TTS-2 is already interoperable, it is an 
operating system. Its twin, TTS-1, is already operating on Pacific Collector. While the 
XTR-1 has yet to be fielded, it “...is based on the modern Radar Open Systems 
Architecture originally developed for the suite of instrumentation radars at the Reagan 
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Test Site” (MIT Annual Report 2008). Because the issues associated with 
interoperability have been previously resolved and the other major parts do not impact 
interoperability, the utility of DoDAF to the Pacific Tracker system was limited. 

The utility of DoDAF seemed to be more associated with the operational views 
than the systems views. The organizational view, OV-4, and the process view, OV-5, 
proved to be the most interesting. They provided additional insight to the non-technical 
areas of the program. As this thesis defined the Pacific Tracker conversion effort, 
establishing processes for mission planning and pre-test event coordination are not part of 
the conversion effort. The design of the processes and organizations necessary for 
successful operation of the Pacific Tracker are candidates for further research. 
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V. SOME IMPLICATIONS FOR OTHER MDA TEST ASSET 
DEVELOPMENT PROJECTS 


The Beaver State conversion project has been successful without the use of 
DoDAF. This was due in large part to major interoperability issues having already been 
resolved. This may not always be the case. Other test asset development projects are 
likely to benefit as the complexity of the test asset interoperability issues. The other 
implication is the interoperability of organizations and processes associated with BMDS 
flight testing should also be considered. 

The development of DoDAF products did not produce significant insights in 
regards to the four major elements, mission equipment electrical power, MDA mission 
personnel berthing, TTS antenna placement, and the communications system. However, 
the development of DoDAF products relative to organizations and processes related to 
the project did provide useful insights. The products OV-4 and OV-5, in particular, were 
useful. These products illustrated some complications with management of the project. 
While outside the scope of this thesis, an OV-5 depiction of the process which provides 
data collections requirements to the Pacific Tracker program, revealed several process 
ambiguities which may lead to confusion in the future. 
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